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(54) Script preprocessing system and method 

(57) A preprocessing script-based data communi- 
cations system and method that embeds information re- 
garding the previous state ol the system within script da- 
ta This effectively imposes a state memory upon what 
would otherwise be a stateless system. Typically, the 
scripts processed by this system are similar in structure 
and format to ordinary HTML scripts, with the addition 



of several commands that facilitate programming em- 
bedded state information. Within systems employing the 
invention a client is afforded the capability of having one 
script influence another by exploiting the preprocessor 
imposed state memory. In addition, the invention pro- 
vides these advantages to a client without the need for 
storing state information on a data system server, there- 
by providing increased system security. 
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Description 



Summary Of The Invention 



Background Of The Invention 

Within large-scale data networks, such as the Inter- 
net, typically many users or clients will have a need to 
receive data from and transmit data to a central server. 
To accommodate, this exchange of data a series of com- 
munications called scripts are typically passed between 
the client computers and the central server. One partic- 
ular type of script is based upon a software language 
known as hypertext mark-up language ('HTML'). This 
language facilitates the presentation of text at a client 
computer in a form contains formatting commands (i.e., 
"mark-up") that are interpreted by the client computer in 
order to present formatted screen. The latest version of 
MOSAIC (a copyrighted software package available 
from the National Center for Supercomputer Applica- 
tions at the University of Illinois in Champagne, Illinois) 
provides a version of HTML that supports a Fill-In Form 
("FIF") friction where the client is provided with a lext- 
based "form" in which he or she may fill-in the blanks. 
This "filled- in" information is then transmitted to the cen- 
tral server. 

While systems employing HTML FIF provide for a 
very effective and easily understood means of commu- 
nicating with a large number of clients via a network, 
they do have the limitation of being "stateless" systems. 
That is to say, within these systems, when a server or a 
client computer begins to process a received script or 
form, it has no information as to what that particular form 
is : exactly what information that lorm will carry, or what 
operations will be executed as a result of the receipt of 
that form. Such systems where a communication arrives 
at a terminal without a history are referred to as stateless 
~ Making reference to the fact that the particular termi- 
nal or server that receives a script is in no particular state 
of preparedness when a given script arrives. 

Since the names and structure of data fields are pe- 
culiar to a given form, and the recipient of that form is 
unable to anticipate the particular structure of a form pri- 
or lo its receipt, it is generally necessary to create a sep- 
arate executable program for each form, in order to 
process received data into a format that can be readily 
interpreted by a server. This being the case, any large 
scale use of forms would require a plethora of special- 
ized programs to reside in the executable directory of 
any HTML FIF server. Together with other administrative 
headaches, this evokes a significant security concern 
as each of these executable programs would have to be 
checked for robustness from a security standpoint. As 
any security system is only as strong as its weakest link, 
if the number of executable programs is minimized, then 
the possibility of a security breach ia also reduced, and 
resources could be concentrated upon insuring that the 
reduced number of programs were subjected to exten- 
sive testing and review. 



The present invention overcomes the deficiencies 
of prior hypertext script-based data communication sys- 
tems by preprocessing script-based data communica- 
tions in a manner that embeds information regarding the 
previous state of the system within the script data. This 
effectively imposes a state memory upon what would 
otherwise be a stateless system. Typically, the scripts 
processed by this system are similar in structure and 
format to ordinary HTML scripts, with the addition of sev- 
eral commands that facilitate programming embedded 
state information. Within systems employing the inven- 
tion a client is afforded the capability of having one script 
influence another by exploiting the preprocessor im- 
posed state memory. In addition, the invention provides 
these advantages to a client without the need for storing 
state information on a data system server, thereby pro- 
viding increased system security. 

Brief Description Of The Drawing 

In the drawing: 

FIG. 1 is a simplified diagram of an exemplary data 
communication system facilitating the practice of 
the invention; and 

FtG. 2 is a simplified diagram depicting an alternate 
data communication system facilitating the practice 
of the invention. 

Detailed Description Of The Invention 

FIG. 1 shows a simplified diagram of an exemplary 
data communication system facilitating the practice of 
the invention. The system includes client computer 101, 
data server 102, and external computer 103. As shown 
data server 1 02 is comprised of script preprocessor 1 04, 
script file memory 1 05 ; and local database memory 1 06, 
and external computer 103 is comprised of response 
processor 1 07, and primary database 1 08. A client com- 
municates with data server 1 02 via client computer 1 01 . 
Client computer 101 can be any computer capable of 
executing HTML-compatible software (such as MOSA- 
IC). As is typically the case for HTML database systems, 
when a communication within the system of FIG. 1 is 
initiated by a client this communication is initiated by a 
client, contacted data server 1 02 transmits an initial text- 
based FIF script file (retrieved from script file memory 
105) to client computer 101. This script file appears to 
the client as an ordinary FIF form having specific blank 
fields that the client fills with appropriate alphanumeric 
information. Each data item representing the various 
filled-in form fields, along with an associated identifier, 
is then transmitted back to data server. 102. The partic- 
ular data structure employed to effect this transmission 
of data consists of an action parameter (which specifies 
the next script file to be transmitted to client computer 
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101 from data server 102) followed by a segmented 
block of input data (each segment reflecting the alpha- 
numeric information entered into each particular field of 
the initial script). While to the client the data system of 
FIG. 1 appears to friction no differently than a standard & 
HTML data system, the fil!ed-in field data transmitted 
from client computer 101 to data sever 102 is employed 
by script preprocessor 1 04 to define the state of the next 
script that will be passed to client terminal 101 . 

Script preprocessor 104 is shown to be linked to "> 
script file memory 105 and local data base memory 106. 
Script file memory 105, in addition to storing the initial 
text -based FIF script transmitted to client computer 101 . 
also contains files that represent a finite set ol text- 
based HTML FIF scripts that contain fields which are is 
defined as a friction of the filled-in field data transmitted 
from client computer 101. These variable HTML FIF 
scripts are referred to as dynamic HTML ("HTML-D") 
scripts. Script preprocessor 1 04 is programmed to rec- 
ognize the particular HTML-D script specified by the ac- 20 
tion parameter received from client computer 101. This 
retrieved HTML-D script is then processed by script pre- 
processor 1 04 as a function of the string of data blocks 
received from client computer 1 0 1 and pre-programmed 
instructions within script preprocessor 104. As a result, ? 5 
additional HTML-D scripts may be retrieved from script 
file memory 105 and transmitted to client computer 101 , 
or if no further information is required from a client, the 
data transmission between client computer 101 and 
script processor 104 may be terminated. 30 

The particular types of processing performed by 
script preprocessor 104 may be broadly categorized as 
text insertion, conditional text insertion, database record 
access, and conditional script redirection. Text insertion 
would result in the particular data block information be- 3S 
ing inserted into the HTML-D script that will be transmit- 
ted back to client computer 101. For example, if a client 
was instructed to fill in a particular field of the initial text- 
based FIF script with his or her name, and data repre- 
senting this name was returned as a data block associ- <o 
ated with an identifier "NAME;" the NAME data could be 
inserted to appear in the next HTML script file that would 
be viewed by the client. Conditional text insertion is a 
process whereby simple text (i.e„ text without embed- 
ded HTML mark-ups) may be inserted dependent upon 
comparison of text strings. For example, if the NAME 
variable data segment is left blank, a default segment 
(such as 'Client" or •Subscriber") could be inserted. An 
example of the performance of database record access 
as a function of the same NAME variable would involve 50 
script preprocessor 1 04 comparing the received NAME 
data block to a particular list of NAME data stored in 
local database memory 106. If the received NAME data 
matched a name upon this stored list, a line of text pro- 
viding a client with a particular message (e.g., "Your ac- ss 
count is overdue", or other personalized information 
such as a phone number or address) would be inserted 
into the next HTML script file to be viewed by the named 



client. Finally, conditional script redirection is a process 
whereby a new HTML-D script file is conditionally sub- 
stituted for the script file that was initially retrieved based 
on comparison of received data. For example, if the 
NAME data failed to match a stored Gsttng of valid cli- 
ents, script preprocessor 104 would redirect an HTML- 
D script facilitating client registration to client computer 
101 (as opposed to displaying the usual HTML-D script 
that would be shown to a valid client). 

As the above described HTML and HTML-0 script 
processing is being performed, script preprocessor is 
collecting requested information Irom the data blocks re- 
ceived from client computer 1 01 . In accordance with the 
programming of script preprocessor 104, all or part of 
this collected information is transmitted to response 
processor 1 07 within external computer 1 03. This trans- 
mission can take place on a real-time basis (as each 
data block is received by script processor 104), at the 
termination of a communication with a given client, or 
simply on a periodic basis. Response processor 107 is 
a data processor adapted to accept client-associated in- 
formation and update primary database to reflect this 
information. This updated information is then transmit- 
ted from primary database 108 to local database 106. 
In this manner, the information in focal database 106 my 
be kept current, and primary database 1 08 remains iso- 
lated from data server 102 (thereby providing an in- 
creased degree of security and data integrity protec- 
tion). As with transmissions from script processor 104 
to response processor 107, information transmissions 
from primary database 108 to local database 106 can 
take place on a real-time basis, at the termination of a 
communication with a given client, or on a periodic ba- 
sis. 

It will be understood that the particular system and 
method described above is only illustrative of the prin- 
ciples of the present invention, and that various modifi- 
cations could be made by those skilled in the art without 
departing from the scope of the present invention, which 
is limited only by the claims that follow. One modification 
would include applying the principles of the invention to 
a system where an external computer was linked to mul- 
tiple data servers, and each of these multiple data serv- 
ers facilitated communication with more than one client 
computer (see FIG. 2). Another modification would be 
applying the invention to systems employing script- 
based languages similar to HTML, and/or to systems 
where the data collected from clients included informa- 
tion other than alphanumeric characters (such as graph- 
ics or other digital data). Furthermore, it will be under- 
stood that text comparison employed in the above de- 
scribed embodiment is merely an example of variable 
manipulation that may performed in processing an 
HTML-D script, and that HTML-D script processing in 
response to any type of boolean manipulation that could 
be performed by a data processor is within the scope of 
this invention. In addition, the invention is not limited by 
any particular mode of information transmission be- 
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tween the various system components. Information can 
be passed between client computers, data servers, and 
external computers via hard-wired networks, wireless 
data links, switched data networks, public telephone 
lines, or any combination thereof. 



Claims 

1. A script-based data communication system com- 
prising: 

at least one client node adapted to receive and 
transmit script-based data; and 
a data server, including a script preprocessor 
and a script file memory, wherein said script 
preprocessor is configured to retrieve data rep- 
resenting particular script files from said script 
file memory and modify said retrieved data in 
response to variables contained in script-based 
data received from one or more client nodes. 

2. A script-bass ed data communication system com- 
prising; 

at least one client node adapted to receive and 
transmit script-based data; 
a data server, including a script preprocessor, 
a script file memory and a database, wherein 
said script preprocessor is configured to re- 
trieve data representing particular script files 
from said script file memory and modify said re- 
trieved data in response to variables contained 
in script-based data received from one or more 
client nodes and data contained in said data- 
base. 

3. The script-based data communication system of 
claim 1 or claim 2, further comprising: 

a data communication line between said data 
server and an external computer, said commu- 
nication link being adapted to facilitate the 
transmission of information from said data serv- 
er to said external computer 

4. The script-based data communication system of 
claim 2, further comprising: 

a data communication link between said data 
server and an external computer, said commu- 
nication link being adapted to facilitate the 
transmission of information from said data serv- 
er to said external computer, and the transmis- 
sion of information from said external computer 
to data server and said data base. 

5. The script-based data communication system of 
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any of the preceding claims wherein hypertext 
mark-up language based scripts are transmitted be- 
tween said data server and said one or more client 
nodes. 

5 

6. The script-based data communication system of 
any of the preceding claims wherein said data serv- 
er is further adapted to transmit said modified re- 
trieved data to at least one client node. 

10 

7. A method for performing script-based data commu- 
nications, comprising the steps of: 

receiving script-based information containing 
is embedded variables from a client node; 

retrieving, in response to said received script- 
based information and the embedded variables 
contained therein, data representing at least 
one particular script file, and modifying said re- 
20 trieved data as a function of said variables con- 

tained in said received script-based data. 

8. A method for performing script-based data commu- 
nications, comprising the steps of: 

2S 

receiving script-based information containing 
embedded variables from a client node; 
retrieving, in response to said received script- 
based information and the embedded variables 
30 contained therein, data representing at least 

one particular script file, and modifying said re- 
trieved data in response to variables contained 
in said received script-based data and other da- 
ta retrieved from a local database. 

55 

9. The method of claim 7 or claim 8 wherein said re- 
ceived script-based information is hypertext mark- 
up language based information. 

40 10. The method of any of claims 7 to 9 further compris- 
ing the step of transmitting said modified retrieved 
data to at least one client node. 

11. The method of any of claims 7 to 10 further com- 
45 prising the step of transmitting information related 
to said received script-based information to an ex- 
ternal computer. 

. 12. The method of any o1 claims 7 to 11 further corn- 
so prising the step of modifying said retrieved data in 
response to information retrieved from an external 
computer. 
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